Fix wrong rows, unfiltered selects and ignored sorts in relationship queries - #3775

• test:unit:resources (rocksdb): 5780 passing, 2 failing. Both failures pass alone (subscriptionReplay, updateAttributesLock watchdog).
• LMDB resources: 4336 passing with subscriptionReplay excluded. That file segfaulted in the full run and passes alone twice.
• test:unit:main: cut off at 58 min with turbo off. Its deployActivation failures pass alone in 0.7 s.
• The full integration suite is left to CI.

• major — resources/Table.ts:8532 — A cached child passes the first predicate, then its recheck goes async (pendingMatch) while a related-select projection (projected) is already running. Nothing observes projected until pendingMatch settles. If the projection rejects first (for example ReadSnapshotExpiredError), Node raises
• major — resources/Table.ts:11649 — Each to-many hop opens its own window of 16 reads (RELATED_READS_IN_FLIGHT), so two to-many hops in one sort path (children.siblings.name) put 16×16 = 256 reads in flight. resources/DESIGN.md:269 says the cap still holds after a to-many hop. The wide-sort test has only one to-many hop, so it c
• minor — resources/search.ts:1807 — The selection object has a filters key and is also passed down as the next level's relationship map. For a to-many relationship named filters, a non-leading condition like children.filters.flag reads that metadata array as filterMap and adopts it as the selection. selection.filters.push at
• minor — resources/Table.ts:7653 — Cancellation is not rechecked after an awaited read:
• minor — unitTests/resources/relationshipQueryContracts.test.js:1 — The test uses require('node:assert/strict'), which house style prohibits. Switch to plain node:assert with explicit strictEqual/deepStrictEqual
• minor — resources/search.ts:1890 — In the sync relationship filter, subObject.some(nextFilter) passes the array index as entry, and the subEntries it builds are thrown away (deferred to a follow-up)
• minor — resources/search.ts:1806 — No select restriction is applied for to-one→to-many hops, OR multi-hop conditions, or OR branches that take the id shortcut (deferred to a follow-up)
• nit — resources/DESIGN.md:270 — The note documents the OR-scope "first evaluated condition wins" gap but links no tracking issue
• nit — resources/Table.ts:11648 — New comments that narrate the code, aggregated into one nit:

Not standing: none. Grok ran 27m (27m from launch to report); the fold adjudication (cursor-grok@30a30424172f-c9897035, claude) took 1m.

• minor — resources/Table.ts:7545 — When a relationship filter sits inside an OR and the select also passes conditions, sort, limit or offset, the select is not narrowed by that filter. _prepareRelationshipSelection reads the filter's restriction once, at resources/Table.ts:7545, while the select step is being built (`reso

Not standing: none. Grok ran 23m (24m from launch to report); the fold adjudication (cursor-grok@36232476e2f1-f71b1bb8, claude) took 1m.

• minor — resources/search.ts:1870 — a to-one hop (no elements) and any OR-scoped multi-hop register no select restriction. preserveForSelect at resources/search.ts:1904-1907 stores only the outer predicate, so select still returns related rows that the condition rejected. This is already deferred as `select-restriction-missing
• minor — resources/search.ts:1870 — a to-many relationship named filters, fromRecord or hasMappings is excluded by SELECTION_BOOKKEEPING (resources/search.ts:1536), so restrictsSelect is false. Example: with related rows g1 (code=yes) and g2 (code=no), filters.code = yes projects both rows
• minor — resources/Table.ts:7659 — cancellation is applied only after matchCandidate settles. If a cancel lands while a nested predicate (for example a loadEntries on grand.great.code) is pending, its storage reads still run to completion and hold a background read slot until they settle
• minor — resources/Table.ts:7778 — four continuations resume without calling checkActive:
• nit — unitTests/resources/relationshipQueryContracts.test.js:360 — the plain OR select test (:360) and the OR test with a limit (:380) assert only rows[1]. rows[0] (or-a, whose child c7 matched) is unasserted because it currently returns children: [] under the deferred first-wins behaviour. A regression on or-a stays green

Not standing: 1 separate-issue, 2 merged. Grok ran 16m (16m from launch to report); the fold adjudication (cursor-grok@12d1f4a0ccf8-3d79cb00, claude) took 1m.

• minor — resources/Table.ts:7660 — when a nested candidate predicate returns false after the transaction has timed out, the code returns SKIP before checkActive runs. If that is the last candidate, the parent row is produced without transactionOpenTooLongError. The join scan at resources/search.ts:1512-1513 checks the guard w
• minor — resources/Table.ts:7782 — the offset and projection continuations check only stopped, which stays false on abortDueToTimeout. They then push or finish() with no read guard, so the last row lands without the timeout error
• nit — resources/Table.ts:7659 — cancellation is seen only after matchCandidate settles, so a nested predicate's in-flight related reads keep running after close(). This is bounded to one predicate evaluation, and the resume returns SKIP
• nit — resources/search.ts:1870 — a to-many relationship named filters, fromRecord or hasMappings gets no select restriction, so non-matching related rows are projected. This is documented in resources/DESIGN.md:394. The test at unitTests/resources/relationshipQueryContracts.test.js:451-461 has only one related row, so it
• nit — unitTests/resources/relationshipQueryContracts.test.js:360 — both OR select tests (lines 360 and 380) assert only rows[1]. The wrong or-a.children result ([], although child c7 matched) is invisible to them. That gap is the deferred first-wins restriction defect, tracked in harper#3762

Not standing: 1 separate-issue. Grok ran 11m (11m from launch to report); the fold adjudication (cursor-grok@39fcf537c09b-c7ed3f1d, claude) took 1m.

Fix relationship-path filter/select/sort defects in resources/search.ts (filterByType ~1784-1895, preserveForSelect ~1858-1882, attributeComparator) and resources/Table.ts (_prepareRelationshipSelection ~7529-7675, getPathValue ~11556-11592). From F-1046: (1) the recordFilter idFilter shortcut (~1828-1845, and its maybeAsync copy ~1891) builds subIdFilter from resolver.from ?? primaryKey even when resolver.to is set, comparing the related PK against the wrong field: guard with (!resolver.to || idFilter.idSet); (2) allowObjectMatching=true makes an array FK (from: childIds) match as a whole array: use !resolver.toMany || Array.isArray(relatedTable.primaryKey); (3) getSubObject's subEntry.map(e => e.value) throws on a dangling FK (HTTP 500): skip nullish entries. From F-1051: (4) preserveForSelect binds fromRecord only for the first non-leading condition (!filtered[firstAttributeName]); accumulate siblings; (5) fromRecord uses value[relatedTable.primaryKey], undefined for composite keys: use entry.key ?? value[pk]; (6) the recursive call passes filterMap?.[name]?.joined (~1794) instead of the sibling map; (7) getPathValue does value?.[attr] on an Array for to-many relationships on the path: map over elements; (8) readCandidate calls getEntry without async: true / freezeRelatedEntry and compile drops maybeAsync (predicate() called synchronously), violating the invariant #3615 wrote into resources/DESIGN.md. If (8) grows large, land it as a second commit in the same PR.

Acceptance

Both staged tests pass on rocksdb and lmdb (P-6647 asserts async-read counts for item 8); existing relationship suites stay green. Show each new test failing on origin/main sources (forced rebuild) before the fix.